如果有，那個環境可能不太健康。

吃著火鍋還唱著歌， 突然 reCAPTCHA 就壞了

說到哪裡了，喔，對。

在 AWS 中，有使用者 (User) 只是有了身分，不等於有權限。
就像是上班沒帶識別證，就過不了門禁系統一樣。

昨天建立好的 User 就像是識別證，大家都知道有這張卡片的人就是公司員工。
但是這張識別證可以去哪些樓層，可以刷過哪些機器，則需要另外訂定規則/政策 (Policy)。

那 Role 呢？昨天提到的 Role 去哪裡了？

Role 比較像是需要時才申請的臨時通行證。
當今天因為業務上的需求，需要進入到機房，就必須先申請機房人員角色。
申請臨時通行證的行為，就稱為 AssumeRole。

為什麼官方強烈建議不要直接使用 Root User ?
Root User 就像是老闆，哪裡都可以去，不需要識別證也可以直接刷臉，
但沒事不會有人天天拖著老闆幫忙開門吧?

系統管理員的需求

維護一套系統需要「系統管理員」。
現在 User 已經建好，接下來就要幫這個管理員設定權限。

兩種方式可以達成這個要求：

• 在 User 上直接設定 Policy
• 建立 Role，讓 User 透過 AssumeRole 使用

方法 1 雖然可行，但是時間一長...

「明明都是系統管理員，怎麼每個人的權限都不一樣？」

「這條權限不是管理員的欸，當初為什麼會有這個設定？」

「如果員工兼任兩種職務，要怎麼區分他現在的操作是哪個角色的權限？」

如果直接將 Policy 設定在 User 上，並不利於管理。
因此更推薦的方法是 Role-based。

Create Role

第一步驟當然就是建立角色。

• 從 IAM 左方選單中找到「角色」後，按下「建立角色」
  

• 有五種角色類型，可以選擇建立的角色是要提供給誰做使用。
  根據選項的不同，會出現的輸入框也不盡相同。
  

• 接下來要定義「系統管理員」這個角色「允許誰使用」，選擇 自訂信任政策。
  

• 下方會出現輸入框，使用的格式為 JSON。
  把它調整成需要的樣子！
  ⚠️ 範例中的 590184072539 與 user-me 需改成自己的帳號與使用者名稱。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowLoginUserWithMFA",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::590184072539:user/user-me"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalAccount": "590184072539"
                },
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        }
    ]
}

• 設定這個 Role 擁有的權限。
  終於走到這一步了真是不容易，尤其打到一半還不小心關掉網頁...
  勾選 AdministratorAccess ，就能給系統管理員需要的全部權限。
  

• 完成所有設定後就可以建立角色囉！
  

小結

User = 身分（識別證）
Role = 權限集合（臨時通行證）

AWS 最佳實務：透過 Role 集中管理權限

下一篇將示範如何加入 MFA + AssumeRole，並實際測試角色權限。

資訊補充

• 那什麼時候適合直接在 User 上設定 Policy？

1. 個人專屬權限
   當某個權限是該 User 個人專屬且不會與其他人共享時
2. 小型組織或簡單環境
   團隊規模很小，且權限結構相對簡單，不會出現角色重疊的情況
3. 暫時性的特殊權限
   短期專案需要的特殊權限
   緊急情況下的臨時授權
   測試用途的暫時性權限
4. 基礎性權限
   所有使用者都需要的基本權限：
   變更自己的密碼
   設定 MFA
   檢視自己的存取金鑰

• AWS 管理最佳實務
  除了建立 User 與 Role 的基本操作外，AWS 官方也提出了一些 IAM 管理最佳實務，能避免權限隨著時間變得難以維護：
  1. 最小權限原則（Least Privilege）
     建立角色時，不要為了方便就直接給予 AdministratorAccess，而是只設定該角色完成工作所需的最少權限。這樣做可以大幅度降低誤操作或帳號被濫用時的風險。
     例如：
  • 開發人員角色 → 只允許操作特定 S3 Bucket 與 DynamoDB Table。
  • 監控角色 → 只允許讀取 CloudWatch Logs 與 Metrics。

2. 使用群組（Group）搭配 Role
   對於需要處理相同工作的多位使用者，應該把他們放進同一個 IAM 群組，從群組上直接設定需要的 Policy，
   再透過 AssumeRole 的方式取得臨時的管理或專案角色。
   • 一致性：同一群組的成員擁有一致的基礎權限，避免因人而異。
   • 易於維護：新增或移除人員時，只需要修改群組成員，不必一個一個調整使用者的 Policy。
3. 定期檢查與稽核（Audit）
   即使一開始設計合理，隨著專案演進，權限需求也可能改變。
   建議定期檢查 Role 與 Policy，確認是否存在過時或不必要的權限，並透過 CloudTrail 或 IAM Access Analyzer 做稽核。